<%- if component.sink? && component.service_provider == "AWS" -%>
### Authentication

Vector checks for AWS credentials in the following order:

1. Environment variables `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY`.
2. The [`credential_process` command][url.aws_credential_process] in the AWS config file. (usually located at `~/.aws/config`)
3. The [AWS credentials file][url.aws_credentials_file]. (usually located at `~/.aws/credentials`)
4. The [IAM instance profile][url.iam_instance_profile]. (will only work if running on an EC2 instance with an instance profile/role)

If credentials are not found the [healtcheck](#healthchecks) will fail and an
error will be [logged][docs.monitoring_logs].

#### Obtaining an access key

In general, we recommend using instance profiles/roles whenever possible. In
cases where this is not possible you can generate an AWS access key for any user
within your AWS account. AWS provides a [detailed guide][url.aws_access_keys] on
how to do this.
<%- end -%>
<%- if component.sink? && component.buffer? && component.batching? -%>

### Buffers & Batches

<%- if component.partition_options.any? -%> 
![][images.sink-flow-partitioned]
<%- else -%>
![][images.sink-flow-serial]
<%- end -%>

The `<%= component.name %>` <%= component.type %> buffers & batches data as
shown in the diagram above. You'll notice that Vector treats these concepts
differently, instead of treating them as global concepts, Vector treats them
as sink specific concepts. This isolates sinks, ensuring services disruptions
are contained and [delivery guarantees][docs.guarantees] are honored.

#### Buffers types

The `buffer.type` option allows you to control buffer resource usage:

| Type     | Description                                                                                                    |
|:---------|:---------------------------------------------------------------------------------------------------------------|
| `memory` | Pros: Fast. Cons: Not persisted across restarts. Possible data loss in the event of a crash. Uses more memory. |
| `disk`   | Pros: Persisted across restarts, durable. Uses much less memory. Cons: Slower, see below.                      |

#### Buffer overflow

The `buffer.when_full` option allows you to control the behavior when the
buffer overflows:

| Type          | Description                                                                                                                        |
|:--------------|:-----------------------------------------------------------------------------------------------------------------------------------|
| `block`       | Applies back pressure until the buffer makes room. This will help to prevent data loss but will cause data to pile up on the edge. |
| `drop_newest` | Drops new data as it's received. This data is lost. This should be used when performance is the highest priority.                  |

#### Batch flushing

Batches are flushed when 1 of 2 conditions are met:

1. The batch age meets or exceeds the configured `batch_timeout` (default: `<%= component.options.batch_timeout.human_default %>`).
2. The batch size meets or exceeds the configured `batch_size` (default: `<%= component.options.batch_size.human_default %>`).
<%- end -%>
<%- if component.options.compression -%>

### Compression

The `<%= component.name %>` <%= component.type %> compresses payloads before
flushing. This helps to reduce the payload size, ultimately reducing bandwidth
and cost. This is controlled via the `compression` option. Each compression
type is described in more detail below:

| Compression | Description |
|:------------|:------------|
<%- component.options.compression.enum.each do |compression| -%>
| `<%= compression %>` | <%= compression_description(compression) %> |
<%- end -%>
<%- end -%>
<% if component.context_options.any? -%>

### Context

By default, the `<%= component.name %>` <%= component.type %> will add context
keys to your events via the <%= option_names(component.context_options).to_sentence %>
options.
<%- end -%>
<% if component.respond_to?(:delivery_guarantee) -%>

### Delivery Guarantee

<% case component.delivery_guarantee -%>
<% when "at_least_once" -%>
This component offers an [**at least once** delivery guarantee][docs.at_least_once_delivery]
if your [pipeline is configured to achieve this][docs.at_least_once_delivery].
<% when "best_effort" -%>
Due to the nature of this component, it offers a
[**best effort** delivery guarantee][docs.best_effort_delivery].
<% end -%>
<% end -%>
<% if component.options.encoding -%>

### Encodings

The `<%= component.name %>` <%= component.type %> encodes events before writing
them downstream. This is controlled via the `encoding` option which accepts
the following options:

| Encoding | Description |
| :------- | :---------- |
<%- component.options.encoding.enum.each do |encoding| -%>
| `<%= encoding %>` | <%= encoding_description(encoding) %> |
<%- end -%>
<%- if component.options.encoding.default.nil? -%>

#### Dynamic encoding

By default, the `encoding` chosen is dynamic based on the explicit/implcit
nature of the event's structure. For example, if this event is parsed (explicit
structuring), Vector will use `json` to encode the structured data. If the event
was not explicitly structured, the `text` encoding will be used.

To further explain why Vector adopts this default, take the simple example of
accepting data over the [`tcp` source][docs.tcp_source] and then connecting
it directly to the `<%= component.name %>` <%= component.type %>. It is less
surprising that the outgoing data reflects the incoming data exactly since it
was not explicitly structured.
<%- end -%>
<%- end -%>

### Environment Variables

Environment variables are supported through all of Vector's configuration.
Simply add `${MY_ENV_VAR}` in your Vector configuration file and the variable
will be replaced before being evaluated.

You can learn more in the [Environment Variables][docs.configuration.environment-variables]
section.
<%- if component.sink? && component.exposing? -%>

### Exposing & Scraping

The `<%= component.name %>` <%= component.type %> exposes data for scraping.
The `address` option determines the address and port the data is made available
on. You'll need to configure your networking so that the configured port is
accessible by the downstream service doing the scraping.
<%- end -%>
<% if component.sink? && component.healthcheck? -%>

### Health Checks

Health checks ensure that the downstream service is accessible and ready to
accept data. This check is performed upon sink initialization.
<%- if component.options.healthcheck_uri -%>
In order to run this check you must provide a value for the `healthcheck_uri`
option.
<%- end -%>

If the health check fails an error will be logged and Vector will proceed to
start. If you'd like to exit immediately upon health check failure, you can
pass the `--require-healthy` flag:

```bash
vector --config /etc/vector/vector.toml --require-healthy
```

And finally, if you'd like to disable health checks entirely for this sink
you can set the `healthcheck` option to `false`.
<%- end -%>
<%- if component.partition_options.any? -%>

### Partitioning

Partitioning is controlled via the <%= option_names(component.partition_options).to_sentence %>
options and allows you to dynamically partition data on the fly.
<%- if component.partition_options.any?(&:templateable?) -%>
You'll notice that Vector's [template sytax](#template-syntax) is supported
for these options, enabling you to use field values as the partition's key.
<%- end -%>
<%- end -%>
<%- if component.options.rate_limit_duration -%>

### Rate Limits

Vector offers a few levers to control the rate and volume of requests to the
downstream service. Start with the `rate_limit_duration` and `rate_limit_num`
options to ensure Vector does not exceed the specified number of requests in
the specified window. You can further control the pace at which this window is
saturated with the `request_in_flight_limit` option, which will guarantee no
more than the specified number of requests are in-flight at any given time.

Please note, Vector's defaults are carefully chosen and it should be rare that
you need to adjust these. If you found a good reason to do so please share it
with the Vector team by [opening an issie][url.new_<%= component.id %>_issue].
<%- end -%>
<%- if component.options.retry_attempts -%>

### Retry Policy

Vector will retry failed requests (status == `429`, >= `500`, and != `501`).
Other responses will _not_ be retried. You can control the number of retry
attempts and backoff rate with the `retry_attempts` and `retry_backoff_secs` options.
<%- end -%>
<%- if component.sink? && component.streaming? -%>

### Streaming

The `<%= component.name %>` <%= component.type %> streams data on a real-time
event-by-event basis. It does not batch data.
<%- end -%>
<%- if component.templateable_options.any? -%>

### Template Syntax

The <%= option_names(component.templateable_options).to_sentence %> options
support [Vector's template syntax][docs.configuration.template-syntax],
enabling dynamic values derived from the event's data. This syntax accepts
[strftime specifiers][url.strftime_specifiers] as well as the
`{{ field_name }}` syntax for accessing event fields. For example:

{% code-tabs %}
{% code-tabs-item title="vector.toml" %}
```toml
[<%= component.type.pluralize %>.my_<%= component.id %>_id]
  # ...
  <%- option = component.templateable_options.fetch(0) -%>
  <%- option.examples.each do |example| -%>
  <%= option.name %> = <%= example.to_toml %>
  <%- end -%>
  # ...
```
{% endcode-tabs-item %}
{% endcode-tabs %}

You can read more about the complete syntax in the
[template syntax section][docs.configuration.template-syntax].
<%- end -%>
<%- if component.options.request_timeout_secs -%>

### Timeouts

To ensure the pipeline does not halt when a service fails to respond Vector
will abort requests after `<%= component.options.request_timeout_secs.human_default %>`.
This can be adjsuted with the `request_timeout_secs` option.

It is highly recommended that you do not lower value below the service's
internal timeout, as this could create orphaned requests, pile on retries,
and result in deuplicate data downstream.
<%- end -%>
<%- if component.options.types && component.options.types.table? -%>

### Types

By default, extracted (parsed) fields all contain `string` values. You can
coerce these values into types via the `types` table as shown in the
[Config File](#config-file) example above. For example:

```toml
[transforms.my_transform_id]
  # ...

  # OPTIONAL - Types
  [transforms.my_transform_id.types]
    status = "int"
    duration = "float"
    success = "bool"
    timestamp = "timestamp|%s"
    timestamp = "timestamp|%+"
    timestamp = "timestamp|%F"
    timestamp = "timestamp|%a %b %e %T %Y"
```

The available types are:

| Type        | Desription                                                                                                          |
|:------------|:--------------------------------------------------------------------------------------------------------------------|
| `bool`      | Coerces to a `true`/`false` boolean. The `1`/`0` and `t`/`f` values are also coerced.                               |
| `float`     | Coerce to 64 bit floats.                                                                                            |
| `int`       | Coerce to a 64 bit integer.                                                                                         |
| `string`    | Coerces to a string. Generally not necessary since values are extracted as strings.                                 |
| `timestamp` | Coerces to a Vector timestamp. [`strftime` specificiers][url.strftime_specifiers] must be used to parse the string. |
<% end -%>